1. Field of the Invention
This invention relates generally to estimating schedules, staffing, costs, and business benefits of software implementation projects, and more particularly to a method and system for self-calibration and refinement of project estimation models for implementing packaged software applications employing normative, constructive, and self-correcting estimation models to determine and support decisions for estimated costs, estimated values, resource allocations, and project schedules.
2. Description of the Related Art
Prepackaged business applications, such as enterprise resource planning (ERP), supply chain management (SCM), supplier relationship management (SRM), product lifecycle management (PLM), and customer relationship management (CRM), offer significant benefits and are critical for an organization's business efficient operations. However, the project planning, configuration, and implementation of prepackaged business applications are time-consuming and costly, and require a variety of skills and expertise that many companies and organizations may not possess. In addition, the costs associated with adopting, ongoing management, and maintenance of business application packages can be staggering.
Well known project planning and costing methodologies include COCOMO (Constructive Cost Model), activity-based costing (ABC) and the ascendant (SAP) method.
COCOMO
COCOMO is a model that estimates cost, effort, staffing, and schedules when planning a new software development activity. COCOMO provides a hierarchy of three increasingly detailed estimation models: (1) Basic COCOMO—a static, single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code, (2) Intermediate COCOMO—computes software development effort as a function of program size and a set of “cost drivers” that include a subjective assessment of product, hardware, personnel and project attributes, and (3) Detailed COCOMO—incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering process.
Activity-Based Costing (ABC)
Activity-based costing (ABC) is an accounting methodology that defines processes, identifies the cost drivers of these processes, determines the unit costs of products and services, and creates reports on agency components that can be used to generate activity- or performance-based budgets. Activity-based costing is based on the following process steps:    (1) Identify activities—perform an in-depth analysis of the operating processes of each responsibility segment. Each process may consist of one or more activities required by outputs,    (2) Assign resource costs to activities—sometimes called “tracing.” Traceability refers to tracing costs to cost objects to determine why costs were incurred. Costs are categorized in three ways:            (a) Direct—costs that can be traced directly to one output. Example: the material costs (varnish, wood, paint) to build a chair,        (b) Indirect—costs that cannot be allocated to an individual output; in other words, they benefit two or more outputs, but not all outputs. Examples: maintenance costs for the saws that cut the wood, storage costs, other construction materials, and quality assurance.), and        (c) General and Administrative—costs that cannot reasonably be associated with any particular product or service produced (overhead). These costs would remain the same no matter what output the activity produced. Examples: salaries of personnel in purchasing department, depreciation on equipment, and plant security,            (3) Identify outputs—identify all of the outputs for which an activity segment performs activities and consumes resources. Outputs can be products, services, or customers (persons or entities to whom a federal agency is required to provide goods or services), and    (4) Assign activity costs to outputs—assign activity costs to outputs using activity drivers. Activity drivers assign activity costs to outputs based on an individual outputs' consumption or demand for activities. For example, a driver may be the number of times an activity is performed (transaction driver) or the length of time an activity is performed (duration driver).
Ascendant Method
The ascendant method is a methodology that provides a consistent, structured, and practical approach to what needs to be done, when it should be done, how it should be done, and how it should be controlled. The ascendant method evolved from SAP AG's AcceleratedSAP (ASAP) method, and IBM practices, practice aids, and methods. The ascendant method supports rolling out a global solution to multiple markets/countries (i.e., several sites implanting SAP in concurrent, staggered go-lives). The ascendant method consists of a number of phases including: market initialization (evaluation), solution preparation, business blueprint, realization, cluster preparation, and cluster go live to sustain. Details of the phases are as follows:
Market initiation (phase 0)—The purpose of the market initiation phase is to complete the basic activities necessary to launch the template system's implementation project in the target markets. Each market initiation implementation project will have its own unique objectives, scope, priorities, and timeline. Typical activities in the market initiation phase include: market initiation planning; market data cleansing, standardization, and mapping workshops; infrastructure planning and deployment; local support organization planning and implementation; market application and system landscape integration; ongoing project and change management; and completion check. Sample key deliverables/results include: early adoption of data standards; local area network (LAN)/wide area network (WAN) deployment strategy; market application and system landscape strategy; and local support organization design. An alternative name for phase 0 is the evaluation phase. The purpose of the evaluation phase is to coordinate activities that are most often part of proposal development.
Solution (project) preparation (phase 1)—The purpose of the solution preparation phase is to commence and execute detailed scope, planning and preparation for the template implementation in the target market. Project preparation builds on the initial scope, strategies, and plans from the project proposal, which is the major deliverable in the evaluation phase, and helps create the project charter. Typical activities in the solution preparation phase include: ongoing project and change management; strategy and preparation for the business blueprint phase; infrastructure requirements; market application and system landscape; scope data conversion and functional design; a first data conversion dry run; and a completion check. Sample key deliverables/results include: project charter; project team organization structure; milestone program plan; detail blueprint phase work plan; and technical infrastructure deployment.
Business blueprint (phase 2)—The purpose of the business blueprint is to identify process requirements in a business blueprint document that defines how the organization intends to run its business. The main activity of the business blueprint phase is to perform a fit/gap analysis between the template system solution and the target market requirement. The approved gaps will determine the detailed design that has to be completed. Typical activities in the business blueprint phase include: ongoing project and Change Management; template fit/gap analysis; update data mapping and conversion design; a second data conversion dry run; document business blueprint; planning, review strategy and prepare for realization phase; infrastructure alignment; market application and system landscape alignment; induction of super and end-user training; role management; and completion check of business blueprint. Sample key deliverables/results include: fit/gap resolution and approval; data mapping and transformation; security processes; confirm end user roles and variants; and a documented business
Blueprint.realization (phase 3)—The purpose of the realization phase is to localize and test the template systems for the target market, in accordance with the requirements documented in the Business Blueprint, and prepare a production ready environment (working production system). Typical activities in the realization phase include: ongoing project and change management; finalize data conversion documentation and developments; a third data conversion dry run; finalizing RICEF documentation and developments; configuration and process test; role management realization; custom development and technical connectivity; infrastructure deployment; cutover planning and simulation; integration testing; finalizing of super and end-user training; and planning and prepare for cluster preparation. Sample key deliverables/results include: market configuration confirmed; market role variants built; market custom development built; cutover plans approved; and a fully tested system.
Cluster (final) preparation (phase 4)—The purpose of cluster preparation phase is to complete preparations for the cluster to go live with the template systems and to complete the plan for transitioning to a day-to-day business operation. Typical activities in the cluster preparation phase include: ongoing project and change management; finalizing RICEF programs; final data conversion; market cutover simulation; market acceptance testing; cluster regression tests; deliver super and end-user training; completion check; and plan and prep for go live and support phase. Examples of key deliverable/results for the cluster preparation phase include: data converted; cut over checklist; contingency plan; production readiness review; legacy retirement plan; and execution of regression test.
Cluster go live and support (phase 5)—The purpose of the go live and support phase is to transition the target market to use the template systems for day-to-day business operations (complete the transition from pre-production environment to a live, stable, productive operation). Typical activities for the go live and support phase include: ongoing project and change management; plan for continuous improvement; plan and preparation for sustain phase; post cluster go-live support; production support; systems monitoring; and system management; and a completion check. Examples of key deliverable/results for the cluster go live and support phase include: production ready systems environment; production capable end users; and production capable support help.
Sustain (phase 6)—The purpose of the sustain phase is to implement a framework for maintaining and improving the performance of the production system.
However, while the currently available project planning and costing methodologies offer aspects of software development project estimation, including the expected time for software development using factors, and project costing and pricing, the available methodologies do not specifically address estimation and implementation of project plans for packaged software applications. Furthermore, none of the present state of the art in software project estimation teaches multi-dimensional implementation project plans, rule-based estimation of service project phase duration, utilization of estimation knowledge bases that externalize estimation parameters for the estimation model configuration, Gantt chart generation of multi-dimensional implementation project plans, staffing and costing for multi-dimensional implementation project plans, and overlapping, grouping, and clustering of rollouts in project plans.
The present state of the art in estimation tools uses ill-fitted models for estimating packaged software applications, and lacks a consistent and efficient method and process for carrying out the estimation. The lack of software tools, and manual calculations based on rules-of-thumb result in significant financial loses every year for packaged application service providers due to inaccurate estimates in terms of cost, implementation strategies, resource usage, etc. Inaccurate estimation results in over-estimates, which lead to lost business opportunities, due to non-competitive bids, and under-estimates, which lead to lost profit on projects that have been under-charged. Furthermore, the ill-fitted models for estimating packaged software applications, the lack of consistent and efficient method and process of estimation, lack of software tools and manual calculation based on rule-of-thumb has had detrimental effects on the productivity of project planners of service providers and customers. The present state of the art in software project estimation requires labor-intensive effort, provides limited scalability for global practice, and lacks of consistency in estimation. The lack of a standard method, process and language, leaves little room for improvement for estimation quality, does not help retain relevant knowledge and experience, and does not help make estimators more efficient and productive.
Therefore there is a need for a system and method that specifically addresses estimation and implementation of project plans for packaged software applications, while providing for multi-dimensional implementation project plans, rule-based estimation of service project phase duration, utilization of estimation knowledge bases that externalize estimation parameters for the estimation model configuration, Gantt chart generation of multi-dimensional implementation project plans, staffing and costing for multi-dimensional implementation project plans, and overlapping, grouping, and clustering of rollouts in project plans.
Glossary
Application software—application software allows end users to accomplish one or more specific (non-computer related) tasks. Typical applications include industrial automation, business software, educational software, medical software, databases, and computer games. Businesses are probably the biggest users of application software, but almost every field of human activity now uses some form of application software. Application software is used to automate all sorts of functions.
Ascendant method—The ascendant method is a methodology that provides a consistent, structured, and practical approach to what needs to be done, when it should be done, how it should be done, and how it should be controlled. The ascendant method evolved from SAP AG's AcceleratedSAP (ASAP) method, and IBM practices, practice aids, and methods. The ascendant method supports rolling out a global solution to multiple markets/countries (i.e., several sites implanting SAP in concurrent, staggered go-lives). The ascendant method consists of a number of phases including: market initialization, solution preparation, business blueprint, realization, cluster preparation, and cluster go live to sustain.
Component business model (CBM)—A component business model represents the entire business in a simple framework that fits on a single page. The component business model is an evolution of traditional views of a business, such as ones through business units, functions, geography, processes or workflow. The component business model methodology helps identify basic building blocks of business, where each building block includes the people, processes and technology needed by this component to act as a standalone entity and deliver value to the organization. This single page perspective provides a view of the business, which is not constricted by barriers that could potentially hamper the ability to make meaningful business transformation. The component business model facilitates to identify which components of the business create differentiation and value. It also helps identify where the business has capability gaps that need to be addressed, as well as opportunities to improve efficiency and lower costs across the entire enterprise.
Constructive model—A constructive model is an intuitive model. In the context of the present invention, constructive models for estimation provide insights and understanding to the estimation, as well as, interactive decision support using what-if analysis and sensitivity analysis.
Crawler—A crawler is a program or automated script that discovers and collects information offered in one or more computer networks.
CRM (customer relationship management)—CRM is an information industry term for methodologies, software, and usually Internet capabilities that help an enterprise manage customer relationships in an organized way. For example, an enterprise might build a database about its customers that described relationships in sufficient detail so that management, salespeople, people providing service, and perhaps the customer directly could access information, match customer needs with product plans and offerings, remind customers of service requirements, know what other products a customer had purchased, and so forth.
EMF (Eclipse Modeling Framework)—EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Rational Rose, then imported into EMF. Most important of all, EMF provides the foundation for interoperability with other EMF-based tools and applications.
ERP (Enterprise Resource Planning)—ERP systems integrate all data and processes of an organization into a unified system. A typical ERP system will use multiple components of computer software and hardware to achieve the integration. A key ingredient of most ERP systems is the use of a unified database to store data for the various system modules.
FMBS (financial and business management system)—The life cycle of each FBMS deployment consists of four key phases.                Business Blueprint Phase: Business process requirements are identified and a Business Blueprint document that defines how the organization intends to run its business within the business management system is developed. Additional activities that occur during this phase include the finalization of the detailed project scope, refinement of the requirements of Reports, Interfaces, Conversions, Enhancements and Forms (RICEF), documentation of the process changes for end users, and establishment of the technical system environment.        Realization Phase: The FBMS system, including RICEF elements is built based on the business process requirements identified in the Business Blueprint Phase, organizational impacts are identified and communicated, and system integration testing occurs.        Final Preparation: The activities that occur during this phase include data conversion from existing systems over to FBMS, final system testing, end user training, and establishment of a Help Desk. The activities that take place during Final Preparation lead up to the determination of final technical and organizational readiness of the system for go-live.        Go-live and Support: During this phase the organization will transition to the system, go-live, and conduct business using the new functionality. End user training continues and post-go live support is provided. Evaluation and monitoring of system transactions also takes place to ensure optimal system performance.        
Gantt chart—A Gantt chart is a graphical representation of the duration of tasks against the progression of time. A Gantt chart is a useful tool for planning and scheduling projects, as well as monitoring a project's progress. A Gantt chart allows for an assessment of how long a project should take, illustrates the dependendcies between tasks, and the order in which tasks need to be carried out. Gantt charts have become a common technique for representing the phases and activities of a project work breakdown structure (WBS), so they can be understood by a wide audience.
GEF (Graphical Editing Framework)—GEF is a framework that was developed for the Eclipse platform (an open source, platform independent software framework, written primarily in Java, and originated by IBM). GEF consists of the following components: draw2d has to be used for the View components, Requests/Commands have to be used to edit the model, Palette of Tools that is offered to the user. Benefits of GEF include: having a graphical representation and being able to edit it; predefined tools for selection, connection creation and others; and the model-view-controller (MVC) concept. GEF allows developers to take an existing application model and quickly create a rich graphical editor.
GMF (Graphical Modeling Framework)—GMF is a framework within the Eclipse platform (an open source, platform independent software framework, written primarily in Java, and originated by IBM), and provides a generative component and runtime infrastructure for developing graphical editors based on the Eclipse Modeling Framework (EMF) and Graphical Editing Framework (GEF).
ISV (Independent Software Vendor)—ISV is a business term for companies specializing in making or selling software, usually for niche markets, such as that for real estate brokers, scheduling for healthcare personnel, barcode scanning and stock maintenance. The specialized software products generally offer higher productivity to organizations than more generalized software such as basic spreadsheet or database packages. An ISV makes and sells software products that run on one or more computer hardware or operating system platforms.
KE (Knowledge engineering)—KE refers to the building, maintaining and development of knowledge-based systems. It has a great deal in common with software engineering, and is related to many computer science domains such as artificial intelligence, databases, data mining, expert systems, decision support systems and geographic information systems.
Knowledge-based system—a computer system that is programmed to imitate human problem-solving by means of artificial intelligence and reference to a database of knowledge on a particular subject.
KPI (Key Performance Indicators)—KPI are financial and non-financial metrics used to quantify objectives to reflect strategic performance of an organization. Key Performance Indicators define a set of values used to measure against. These raw sets of values fed to systems to summarize information against are called indicators. Indicators identifiable as possible candidates for KPIs can be summarized into the following sub-categories:                Quantitative indicators which can be presented as a number.        Practical indicators that interface with existing company processes.        Directional indicators specifying whether an organization is getting better or not.        Actionable indicators are sufficiently in an orgainzation's control to effect change        
MDA (Model-Driven Architecture)—MDA is a software design approach introduced by the Object Management Group (OMG) that supports model-driven engineering of software systems. MDA provides a set of guidelines for structuring specifications expressed as models. The MDA approach first defines system functionality using a platform-independent model (PIM) using an appropriate Domain Specific Language. Then, given a Platform Definition Model (PDM) corresponding to CORBA (common object request broker architecture), DotNet, the Web, etc., the PIM is translated to one or more platform-specific models (PSMs) that computers can run, using different Domain Specific Languages, or a General Purpose Language like Java, C++, Python, etc. Automated tools generally perform the translations between PIM and PSM. MDA principles can also apply to other areas such as business process modeling where the PIM is translated to either automated or manual processes. The MDA model is related to multiple standards, including the Unified Modeling Language (UML), the Meta-Object Facility (MOF), the XML Metadata interchange (XMI), Enterprise Distributed Object Computing (EDOC), the Software Process Engineering Metamodel (SPEM), and the Common Warehouse Metamodel (CWM). Note that the term “architecture” in Model-driven architecture does not refer to the architecture of the system being modeled, but rather to the architecture of the various standards and model forms that serve as the technology basis for MDA.
Metamodeling in computer science and related disciplines is the construction of a collection of “concepts” (things, terms, etc.) within a certain domain. A model is an abstraction of phenomena in the real world, and a metamodel is yet another abstraction, highlighting properties of the model itself. This model is said to conform to its metamodel like a program conforms to the grammar of the programming language in which it is written. Common uses for metamodels are:                As a schema for semantic data that needs to be exchanged or stored        As a language that supports a particular method or process        As a language to express additional semantics of existing information        
Model—in the world of dynamic systems, modeling provides the foundation of how knowledge is captured and used. As a general definition, a model is a representation of something in, or intended for, the real-world; its purpose is to describe specific characteristics, behavior and relationships with sufficient accuracy that it is an acceptable representation of what it describes. In the context of dynamic systems a model is a machine-readable representation of the components comprising a system and the policies that govern the system: it provides sufficient detail for systems to adapt dynamically to changing conditions, and changes in business requirements, through intelligent automation of the management function. In the development of information technology solutions, models may be used to manage complexity and to communicate system requirements between business stakeholders, solution and system architects, developers, and operations personnel. Model systems are formed from a series of interconnected objects. The objects each represent a specific characteristic of the system, including the desired state of that characteristic, the range of states it is capable of being and what resources it needs. The interconnections between these objects describe the nature of the relationship between these characteristics. For example, one object may rely on the other in order to exist, in which case one object is hosting the other. Alternatively, one object may simply provide a service to the other and the two objects are peers. Reduced to its simplest form, a model can be illustrated as a series of boxes and lines. The boxes represent systems, subsystems and components. The lines in the model diagram represent different kinds of relationships. These lines might represent a hosting relationship, lines of communication, and also indicate dependencies. Each element in a model, a system or a relationship belongs to a class and has attributes, constraints and policies. When creating a model, the designer places and interconnects the elements and specifies the desired values for the attributes.
Model-driven business transformation—A model-driven business transformation utilizes a multi-layer model approach to link business and IT semantics. The upper layers of the model represent business semantics in the terms familiar to business executives, business managers and analysts such as key performance indicators (KPI), operational metrics, business processes, activities and governance. The lower layers of the model represent IT architecture comprising a wide range of services implemented in IT infrastructure such as service-oriented architecture. The vision of this multi-layer model is to enable IT solutions to accurately reflect and be driven by business intent. The key to this multi-layer model is that the layers are linked in meaningful ways, so changes in one layer can ripple through other layers. The representation and enforcement of the semantics of the different layers and also of the connections between the layers is essential to the model-driven approach. This approach provides a convergence of the business and IT models using a multi-layer model, which tightly couples the business and IT models.
MOF (Meta-Object Facility)—MOF is an Object Management Group (OMG) standard for Model Driven Engineering. MOF provides a metadata management framework, and a set of metadata services to enable the development and interoperability of model and metadata driven systems. Examples of systems that use MOF include modeling and development tools, data warehouse systems, metadata repositories, etc. MOF originated in the Unified Modeling Language (UML), and was created as a metamodeling architecture to define the UML. MOF is designed as a four-layered architecture. It provides a meta-meta model at the top layer, called the M3 layer. This M3-model is the language used by MOF to build metamodels, called M2-models. The most prominent example of a Layer 2 MOF model is the UML metamodel, the model that describes the UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe the real-world.
MVC (Model-view-controller)—MVC is an architectural pattern used in software engineering. In complex computer applications that present lots of data to the user, one often wishes to separate data (model) and user interface (UI) (view) concerns, so that changes to the user interface do not affect the data handling, and that the data can be reorganized without changing the user interface. The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. The MVC paradigm is a way of breaking an application, or even just a piece of an application's interface, into three parts: the model, the view, and the controller. MVC was originally developed to map the traditional input, processing, output roles into the graphical user interface (GUI) realm:
Input-->Processing-->Output
Controller-->Model-->View
The user input, the modeling of the external world, and the visual feedback to the user are separated and handled by model, viewport, and controller objects. The controller interprets mouse and keyboard inputs from the user and maps these user actions into commands that are sent to the model and/or viewport to effect the appropriate change. The model manages one or more data elements, responds to queries about its state, and responds to instructions to change state. The viewport manages a rectangular area of the display and is responsible for presenting data to the user through a combination of graphics and text.
Multi-attribute utility (MAU) models—MAU are mathematical tools for evaluating and comparing alternatives to assist in choosing among them. They are designed to answer the question, “Given the factors we care about, what's the best choice?” MAU models are based on the assumption that the desirability of a particular alternative depends on how well its attributes measure up against key evaluation factors. For example, if you are shopping for a new car, you will prefer one over another based on how well each one scores on the factors you think are important, such as price, reliability, safety ratings, fuel economy, and style. MAU models offer a structured way to weight, evaluate, and compare possible alternatives. They offer a quantifiable method for choosing among options. A MAU model can also be used to conduct sensitivity analysis to explore the consequences of changing the attributes, their weights, or the scores they receive. Since the model usually is embodied in a simple spreadsheet, it is possible to make any number of changes and review the results. For example, if it appears that some attribute is too important in determining the results, the weights can be adjusted to produce different overall scores and to see if those differences really matter to the final decision. MAU can be used to manage complex comparisons by converting the evaluation to a numerical score while still presenting the logic behind the score. One of the most useful benefits of using a MAU model is that it makes clear to all involved the basis on which the alternatives are being evaluated. This is particularly important in group decision-making situations in which many different points of view and decision alternatives have to be reviewed and taken into account. To be effective the MAU requires a group consensus on the attributes in the model and on the weights to be used to indicate their relative importance. However, it may be very difficult and time consuming, or even impossible to achieve consensus on very controversial decisions. MAU models can be applied in all kinds of decision situations and are often used in the technical and programmatic parts of procurement evaluations.
Normative model—A normative model is a generic model for different customers and systems. In the context of the current invention normative models for estimation support various ISVs and packaged software applications, various clients, evolving situations, and parameter externalization in ontology and autonomic configuration.
OWL (Web ontology language)—OWL is a language for defining and instantiating Web ontologies. An OWL ontology may include descriptions of classes, along with their related properties and instances. OWL is designed for use by applications that need to process the content of information instead of just presenting information to humans. It facilitates greater machine interpretability of Web content than that supported by XML, RDF, and RDF Schema (RDF-S) by providing additional vocabulary along with a formal semantics. OWL is seen as a major technology for the future implementation of a Semantic Web. It is playing an important role in an increasing number and range of applications, and is the focus of research into tools, reasoning techniques, formal foundations and language extensions. OWL was designed to provide a common way to process the semantic content of web information. It was developed to augment the facilities for expressing semantics (meaning) provided by XML, RDF, and RDF-S. Consequently, it may be considered an evolution of these web languages in terms of its ability to represent machine-interpretable semantic content on the web. Since OWL is based on XML, OWL information can be easily exchanged between different types of computers using different operating systems, and application languages. Because the language is intended to be read by computer applications, it is sometimes not considered to be human-readable, although this may be a tool issue. OWL is being used to create standards that provide a framework for asset management, enterprise integration, and data sharing on the Web.
PIM (platform-independent model)—PIM is a model of a software or business system that is independent of the specific technological platform used to implement it. A PIM exhibits a specified degree of platform independence so as to be suitable for use with a number of different platforms of similar type. Examples of platforms range from virtual machines, to programming languages, to deployment platforms, to applications, depending on the perspective of the modeler and application being modeled.
PSM (platform-specific model)—PSM is a model of a software or business system that is linked to a specific technological platform (e.g., a specific programming language, operating system, or database). Platform-specific models are indispensable for the actual implementation of a system. A PSM is a view of a system from the platform specific viewpoint. A PSM combines the specifications in the PIM with the details that specify how that system uses a particular type of platform.
RICEF (Reports, Interfaces, Conversion, Enhancements, and Forms)—RICEF is used to collectively indicate the application development in SAP configuration and installation projects. The amount and difficulty levels of these objects determine the level of application development efforts in such projects. More specifically, R—Reports: R refers report programming. Firstly classical report programming, WRITE statement; then it means ALV (Approved Vendor Lists) programming with either ALV function modules or ABAP (a programming language for SAP's Web application server) objects; I—Interfaces are ALE (Application Link Enabling)/IDOC (Intermediate Document) developments. Not only development, ABAP programming for IDOCs, also IDOC customization, management. C—Conversion: BDC (Batch Data Communication) programming, batch input function modules, BDCDATA structure, CALL TRANSACTION. Also conversion specifically refers to conversion programs for standard batch input programs. E—Enhancements are user-exits and the object oriented model of user-exits that is BADIs (Business Add-Ins). F—Forms are SAPscript forms, SAPscript print programs, and SmartForms.
SAP (Systems Applications and Products)—SAP applications have the capability to manage financial, asset, and cost accounting, production operations and materials, personnel, plants, and archived documents in a client server environment. SAP is made up of individual, integrated software modules that perform various organizational system tasks. SAP applications are a product of the SAP Corporation based in Germany, and provide customers with the ability to interact with a common corporate database for a comprehensive range of applications. SAP is made up of individual, integrated software modules that perform various organizational system tasks.
SCM (supply chain management)—SCM is the oversight of materials, information, and finances as they move in a process from supplier to manufacturer to wholesaler to retailer to consumer. Supply chain management involves coordinating and integrating these flows both within and among companies. The ultimate goal of any effective supply chain management system is to reduce inventory (with the assumption that products are available when needed). Supply chain management flows can be divided into three main flows: product flow, information flow, and financial flow. The product flow includes the movement of goods from a supplier to a customer, as well as any customer returns or service needs. The information flow involves transmitting orders and updating the status of delivery. The financial flow consists of credit terms, payment schedules, and consignment and title ownership arrangements. There are two main types of SCM software: planning applications and execution applications. Planning applications use advanced algorithms to determine the best way to fill an order. Execution applications track the physical status of goods, the management of materials, and financial information involving all parties.
Semantics—Semantics refers to the aspects of meaning that are expressed in a language, code, or other form of representation. Semantics is contrasted with two other aspects of meaningful expression, namely, syntax, the construction of complex signs from simpler signs, and pragmatics, the practical use of signs by agents or communities of interpretation in particular circumstances and contexts. By the usual convention that calls a study or a theory by the name of its subject matter, semantics may also denote the theoretical study of meaning in systems of signs.
Semantic Web—The semantic web is an evolving extension of the World Wide Web in which web content can be expressed not only in natural language, but also in a form that can be understood, interpreted and used by software agents, thus permitting them to find, share and integrate information more easily.
UML (unified modeling language)—UML is a standardized specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model. UML is officially defined at the Object Management Group (OMG) by the UML metamodel, a Meta-Object Facility metamodel (MOF). Like other MOF-based specifications, the UML metamodel and UML models may be serialized in XMI. UML was designed to specify, visualize, construct, and document software-intensive systems. UML is not restricted to modeling software. UML is also used for business process modeling, systems engineering modeling, and representing organizational structures. UML possess the ability to model distributed systems using classes, relationships, inheritance, and composition.
Value drivers—Value drivers are key business parameters that capture business impact at a measurable metric level and are translated into business values. Generic value drivers include revenue growth, margin improvement, and increased capital efficiency, etc.
Value modeling—value modeling identifies and maps the enterprise's key business and IT value drivers, and links the drivers to the measurable business and financial benefits. The value model also helps tracking the performance and showing realized value during and after the IT implementation.
XMI (XML Metadata Interchange)—XMI is an OMG standard for exchanging metadata information via Extensible Markup Language (XML). XMI can be used for any metadata whose metamodel can be expressed in Meta-Object Facility (MOF). The most common use of XMI is as an interchange format for UML models, although it can also be used for serialization of models of other languages (metamodels). One purpose of XML Metadata Interchange (XMI) is to enable easy interchange of metadata between UML-based modeling tools and MOF-based metadata repositories in distributed heterogeneous environments. XMI is also commonly used as the medium by which models are passed from modeling tools to software generation tools as part of model-driven engineering. XMI integrates four industry standards:                XML—eXtensible Markup Language, a World Wide Web Consortium (W3C) standard.                    UML—Unified Modeling Language, an OMG modeling standard.            MOF—Meta Object Facility, an OMG language for specifying metamodels.            MOF Mapping to XMIThe integration of these four standards into XMI allows tool developers of distributed systems to share object models and other metadata.                        
WBS (work breakdown structure)—A WBS is a list of tasks that, if completed, will produce the final product. The way the work is broken down dictates how it will be done. There are many ways to decompose a project into tasks. The project can be broken down by feature, by project phase (requirements tasks, design tasks, programming tasks, QA tasks, etc., or by some combination of the two. A Work Breakdown Structure is a fundamental project management technique for defining and organizing the total scope of a project, using a hierarchical tree structure. The first two levels of the WBS (the root node and Level 2) define a set of planned outcomes that collectively and exclusively represent 100% of the project scope. At each subsequent level, the children of a parent node collectively and exclusively represent 100% of the scope of their parent node. A well-designed WBS describes planned outcomes instead of planned actions. Outcomes are the desired ends of the project, and can be predicted accurately; actions comprise the project plan and may be difficult to predict accurately. A well-designed WBS makes it easy to assign any project activity to one and only one terminal element of the WBS.